DDS-Suite - A Dynamic Data Acquisition, Processing, and 
Analysis System for Wind Tunnel Testing 


Nathan J. Burnside* 

NASA Ames Research Center, Moffett Field, CA 94035 


Wind Tunnels have optimized their steady-state data systems for acquisition and analysis 
and even implemented large dynamic-data acquisition systems, however development of 
near real-time processing and analysis tools for dynamic-data have lagged. DDS-Suite is a set 
of tools used to acquire, process, and analyze large amounts of dynamic data. Each phase of 
the testing process: acquisition, processing, and analysis are handled by separate 

components so that bottlenecks in one phase of the process do not affect the other, leading to 
a robust system. DDS-Suite is capable of acquiring 672 channels of dynamic data at rate of 
275 MB / s More than 300 channels of the system use 24-bit analog-to-digital cards and are 
capable of producing data with less than 0.01° of phase difference at 1 kHz. System 
architecture, design philosophy, and examples of use during NASA Constellation and 
Fundamental Aerodynamic tests are discussed. 


I. Introduction 

R ESEARCHERS at NASA Ames have developed and implemented a suite of dynamic data tools for use in wind 
tunnels to acquire, process, and analyze large amounts of dynamic data with minimal human input. Use of the 
new dynamic data system in eight major aeroacoustic tests in the Space Shuttle, Constellation, and Fundamental 
Aerodynamics programs has proven its reliability and usefulness for high channel-count dynamic-data testing. Fully 
processed preliminary data are available for analysis and plotting minutes after acquisition, giving researchers the 
tools to make test matrix or priority changes. The system is modular and scalable allowing for rapid deployment in 
tests needing only a handful of channels or hundreds of channels. Current hardware allows for approximately 275 
MB / s of data acquisition over 672 channels of discretely sampled data. Sample rates of up to 204.8 kHz are 
sustainable for sample durations of 20 seconds. 

This paper will discuss the design philosophy of the 672-channel Dynamic Data System Suite ( DDS-Suite ) and 
its applications for dynamic-data testing in the Ames Unitary Wind Tunnels and the Arnold Engineering 
Development Center (AEDC) 40- by 80-Foot Wind Tunnel. There are three main components of DDS-Suite : (1) 
LAMDA , the acquisition software; (2) Pro cess Scheduler, the processing portion of the suite; and (3) QueryGUI, the 
data plotting and analysis tool. Specific application to a number of Constellation and Space Shuttle tests will be 
discussed highlighting the robustness and adaptability of the DDS-Suite. 

II. Background 

Wind tunnel data acquisition and processing has evolved over the last seven decades with large gains in data 
accuracy, precision, quantity, and productivity rates. Production wind tunnels like the NASA Ames 11-Foot and 
9x7-Foot have focused on optimizing their steady-state data systems like those that acquire and process tunnel 
conditions, steady surface-pressures, model position information, temperature data, and balance measurements. The 
Standard Data System (SDS) offers real-time steady-state data viewing, analysis, and plotting and has been in 
constant use for the last 15 years * 1 . Dynamic-data acquisition systems that collect data for accelerometers, 
microphones, and unsteady surface-pressures however, lagged in the evolutionary process. Closed-loop dynamic- 
data acquisition, processing, and analysis tools were primitive until the latter half of the last decade. The ability to 
acquire large amounts of dynamic-data existed, but fast and efficient methods of processing and analysis did not. 
DDS-Suite automates the acquisition and processing of test data, making it available for plotting minutes after 
testing. 
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IS-21, a 3% Space Shuttle aeroacoustics test supporting the return-to-flight efforts in the wake of the Space 
Shuttle Columbia accident drove the initial development of DDS-Suite. During test planning it became apparent that 
existing dynamic-data systems did not have the capacity or processing throughput to meet the test requirements. 
DDS-Suite was designed to make preliminary acoustic data from 117 model mounted unsteady-pressure sensors 
available for plotting less than 5 minutes after acquisition 2 . Network communications with SDS created a closed- 
loop dynamic-data triggering process that greatly improved productivity. Automated processing created narrowband 
and 1/3-octave data that were inserted into a database for instant data availability. The productivity of IS-21 can be 
compared directly with IS-2, a Space Shuttle acoustic test performed in the 1970’s with 120 transducers. Data from 
IS-2 was recorded on analog tapes and took more than 2 years to reduce and analyze 3 compared with IS-21 that used 
five data analysts to plot and analyze data in near realtime. 

III. DDS-Suite Design 

The global design philosophy for DDS-Suite was to create 
a robust, scalable, user-friendly software and hardware 
system that would have minimal impact on normal wind 
tunnel operations. Three distinct phases are involved in 
dynamic data measurements: (1) data acquisition; (2) 
processing; and (3) analysis. Each phase of operation in 
DDS-Suite is independent. Figure 1 shows the major software 
components of each phase and the common links. ProcQueue 
is the processing queue and it links the acquisition and 
processing phases. The ProcessedData database stores results 
and links processing with analysis. A bottleneck in 
processing does not affect data acquisition or the availability 
of existing processed data. Acquisition and processing 
require minimal user interaction once the system is started 
providing an enormous throughput of data. 

All data phases are equally important for obtaining the 
final results, but data acquisition carries the most risk 
because of wind tunnel operation costs. Total wind-on costs, including power can approach $10,000 / hour making 
data acquisition efficiency paramount. LAMDA , the data acquisition program was designed to acquire and store data 
as quickly as possible while maintaining robustness. Scalability was an important consideration in system design. 
Response to doubling channel count or the number of data analysts, needed to be as simple as adding twice as many 
computers. Achieving a scalable architecture in DDS-Suite was accomplished differently for each phase of the data 
handling and will be discussed below. 

A. Acquisition 

LAMDA is the data acquisition portion of DDS-Suite. It was designed to interact with SDS, the wind tunnel static 
data system or as a stand-alone user driven system. The system consists of at least one master computer and a 
hardware chassis containing analog-to-digital converters. Slave computers and chassis are added to increase system 
channels. Communication with motor controllers and other measurement systems such as Pressure Sensitive Paint 
(PSP) system greatly increases productivity and is coordinated through the master computer. 

HP and Agilent 1432 and 1433 data acquisition cards operating in VXI chassis were the development target for 
LAMDA. The practical limit for the number of 1433 8-channel A/D cards in a VXI chassis is nine because of power 
limitations. It is possible to span the VXI bus across multiple chassis with MXI-bus extender cards, but all of the 
data from the extended bus has to flow to the host computer using an IEEE 1394a (Firewire 400) connection. This 
limitation drove the modular architecture of one computer host for each chassis of data acquisition hardware. By 
using a master / slave arrangement, computers and chassis are added to meet the channel requirements while 
maintaining data throughput. The scalable architecture of DDS-Suite allows for test complexity to increase without 
effecting productivity. Recent improvements allow for combinations of older VXI and newer PXI hardware. Figure 
2 shows a typical system deployment for a high-channel count test; note that there is one master computer and 1 1 
slaves. 

LAMDA uses Remote Procedure Calls (RPCs) to communicate with SDS, creating a closed-loop data acquisition 
process that is synced with model movement and wind tunnel conditions. Communication between the master and 
slave data acquisition computers is accomplished using network TCP packets on the gigabit network (1000 Mb/s). 
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(1) (2) (3) 



Figure 1. Each phase of DDS-Suite has several 
software components. 


The data acquisition chassis are all triggered at the same time using a hardware trigger. All triggering lines are equal 
lengths to maintain phase, although this is not indicated in Fig. 2. 

During a typical pitch-pause sweep the Facility Control System (FCS) stops at each angle-of-attack in the run 
vector and notifies SDS that the tunnel is on condition. Meanwhile the master computer polls SDS to see if the 
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Figure 2. LAMDA system schematic showing a typical 576-channel deployment. Note that the data inputs to 
the analog-to-digital converters are not shown. 

tunnel is on condition. This polling occurs at a rate of 10 Hz. When SDS confirms that the tunnel is on condition, the 
master commands SDS to take a static data point and then asks SDS the run and sequence number of the data being 
acquired. The run and sequence information is sent to all of the slaves via the gigabit network. Each slave replies 
with a positive echo indicating they are ready for dynamic data acquisition. A hardware trigger sent by the master to 
all of the A/D chassis starts data acquisition. After each slave finishes acquiring its data, it checks back in with the 
master and then stores the data to a local hard disk in a temporary folder. After storing the data, each acquisition 
computer inserts information about the last data point into the ProcQueue database. Only after each slave completes 
data acquisition will the master computer tell SDS that the data point is complete. SDS then tells FCS that the data 
point is complete and it moves the model or tunnel to the next condition in the run vector. Typical 5-second data 
points take about 6 seconds from start to finish and the time to move the model varies, but 3 to 4 seconds is 
common. 

FileMover is a software program that runs on each acquisition computer but is independent of LAMDA. As its 
name implies, FileMover moves files from the temporary directory into a directory structure on the local hard drive 
and onto a network file server that is organized by test, run, and sequence number. Once two copies of the file are 
made the file in the temporary directory is deleted and a status flag in the ProcQueue database is changed to indicate 
the file has been moved to the server and is ready for processing. Duplicate copies of the data are important to 
reduce the inherent risk of computer or hard drive failure. Decoupling the acquisition program from network file 
transfers reduces the acquisition cycle time and improves reliability. 
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LAMDA was originally designed to use the VXI 1433a, 1433b, and 1432a A/D cards manufactured by HP, 
Agilent, or VXI Technologies. The 1433 cards are 8 -channel 16-bit analog-to-digital converters capable of sampling 
simultaneously at 196.6 kSamples per second. Input ranges are user selectable; the smallest range is ±0.005 volts 
and the largest is ±10 volts. The 1432a cards are 16-channel, 16-bit analog-to-digital converters with a maximum 
sample rate of 51.2 kSamples per second. Their smallest input range is ±0.1 volts and the largest is ±20 volts. The 
VXI hardware performs extremely well, but without complicated inter-chassis connections, simultaneous sampling 
is limited to one chassis. The practical limit of cards in each chassis is nine, meaning the maximum number of 
correlated channels is 72 or 144 for the 1433 and 1432 cards, respectively. 

Prior to the Crew Exploration Vehicle (CEV) 51-AS test in October of 2008, LAMDA received a major upgrade 
and expanded capability. LAMDA was modified to control a 300-channel PXI based data system in addition to the 
existing 300-channel VXI system. The National Instruments (NI) system uses PXI-4462 analog-to-digital converters 
with 24-bit resolution and samples rates as high as 204.8 kSamples per second. The smallest input range is ±0.316 
volts and the largest is ±42.4 volts. Each data acquisition chassis has a PXI-6652 timing card connected to a master 
timing chassis with a PXI-6652 timing card for each acquisition chassis as shown in Fig. 2. The dedicated timing 

chassis allows the sample clock and trigger signals to be 

distributed to several hundred channels creating a Chassis-Chan Chassis-Chan Phase (deg) 
massive high-speed data system with simultaneous 1-4 -0 0009 

sampling across all channels. ~ 0~0015 

Phase performance of the PXI system was evaluated 1 

using six chassis with 48 channels each. Testing was — — -0.0007 

performed with a 1 kHz, 1 volt sine wave. Phase was Izl 3-1 -0.0018 

measured between several channels and follows the 1-1 4-1 -0.0003 

nomenclature chassis-channel. The worst phase i_i 5.1 -0.0007 

performance was between 1-1 and 3-1 at -0.0018° and j - j 0~0015 

the best performance was -0.0003° between 1-1 and 4-1. * . . — - — , , , * , — : : , 

rj, 1 1 1 i , , u n tivt Table 1. LAMDA phase measurements using a 1 

Table 1 summarizes the phase test results for the PXI , TT ^ . 

kHz, 1 volt sine wave. 

system. 


Chassis-Chan 

Chassis-Chan 

Phase (deg) 

1-1 

1-4 

-0.0009 

1-1 

1-48 

-0.0015 

1-1 

2-1 

-0.0007 

1-1 

3-1 

-0.0018 

1-1 

4-1 

-0.0003 

1-1 

5-1 

-0.0007 

1-1 

6-1 

-0.0015 


Table 1. LAMDA phase measurements using a 
kHz, 1 volt sine wave. 


B. Processing 

The ProcQueue database is the central coordinator for data processing and ensures that each data file is 


processed only once. It contains test, run, 
sequence number, file name, location status and 
processing status, and processing priority 
information for every file acquired by DDS- 
Suite. The ProcQueue database is updated 
automatically by several components of DDS- 
Suite, however it can be manipulated manually 
using ProcQueueAdmin. Radio buttons based 
on the file status are used to filter the data files 
displayed and status changes are made by 
highlighting files and using the status change 
buttons as shown in Fig. 3 where run 70 
sequence 1 is processing, run 70 sequence 2 is 
waiting to be processed, and run 70 sequence 4 
is still on the acquisition computer local disks. 
Each request to the ProcQueue database for a 
set of files to process, generates a unique 
process number, this number is assigned to the 
processed flag for each file in the set so they are 
easily identifiable. By default all files have the 
same priority for processing and the queue 
operates on a first in first out scheme, however 
the priority can easily changed using 
ProcQueueAdmin if desired. 



Figure 3. ProcQueueAdmin showing the status of 3 data 
points. There are 12 files associated with each point. 


4 

American Institute of Aeronautics and Astronautics 



ProcessScheduler is the software that actually does the processing. Following the modular, scalable architecture 
any number of independent processing machines can be deployed for a given wind tunnel test. Each instance of 
ProcessScheduler sends a request to the ProcQueue database asking for the next set of files that need processing. 
The database returns either a zero indicating there are no files to process or a unique process number. The database 
software handles request such that files are in use by only one instance of ProcessScheduler at a time. A large test 
deployment like the one shown in Fig. 2 would have eight computers processing data in near real-time. 

ProcesssScheduler is customized for each test but for most applications it processes time history data to create 
narrowband spectra, 1/3-octave levels, and overall sound pressure levels (OASPL) scaled to full-scale flight levels. 
The processed data are inserted into a Firebird 1.5.2 database for storage and analysis. The relational database 
includes information about wind tunnel conditions, model positions, and the processed data. The database structure 
is capable of supporting multiple tests allowing for data comparison. Figure 4 shows the database schema for the 
processed data. The primary key(s) for each table are shown in orange. Notice the connections between tables show 
a one-to-many mapping for the TestDataPoint and channelinfo tables. TestDataCache is a table to store unique 
values of each data parameter in the TestDataPoint table to improve Query GUI start times. Entries to the 
TestDataCache table are transparent to the user and are handled by stored procedures and table triggers. 


IS-21 Dynamic Data Results Schema (v.9) 


TestDataPoint 


testPointld: biglnt 
Test: integer 
Run: smallint 
Seq: smallint 
Mach: float 
Pt: float 

PtUnit: varchar(20) 
Ps: float 

PsUnit: varchar(20) 
Q: float 

Qunit: varchar(20) 
Alpha: float 
Beta: float 
Re: float 
T: float 

Tunits: varchar(20) 
TT: float 

TTUnit: varchar(20) 
PAL: smallint 
dataQuality: smallint 
V: float 

Vunit: varchar(20) 
IFR: smallint 
Qplane: smallint 


1 


1 


1 



Figure 4. Relational database schema for the ProcessedData database. Primary key(s) for each table 
are indicated by red variables. 


C. Analysis 

The third component of DDS-Suite is Query GUI, an analysis and plotting program that allows the user to create 
database queries using drop down menus 4 . Query GUI and the ProcessedData database highlight the scalability of 
DDS-Suite by accommodating user scenarios ranging from a single user with a laptop to dozens of users accessing 
the data via server. Its simple graphical user interface allows users to create complex database searches. 
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Figure 5 shows Query GUI and 
several of the parameters available 
for query. Users make graphical 
selections of search criteria and then 
build their query. Graphical 
selections are converted to a single 
SQL statement for execution on the 
ProcessedData database. Once a 
query is executed results are 
returned to Query GUI where the 
user can view the data or choose 
from several plotting options. 1/3- 
octave plotting is often the most 
useful as shown in Fig. 6. Large data 
sets can also be condensed into a 
grid plot as shown in Fig. 7, where 
x-axis of the grid plot is 1/3 -octave 
frequency and the y-axis is sensor 
channel; color indicates the 
amplitude. This type of plot is very 
useful when sensors are distributed 
evenly over the surface of a vehicle 
because acoustic hotspots in both 
frequency and location are 
identified. 

Query GUI was developed for 
vehicle aeroacoustic environment testing where 
zonal acoustic environments are defined by the 
envelope of the 1/3 -octave spectra within the each 
zone. Query GUI and the ProcessedData database 
have a search function called maximax for finding 
an envelope of all search criteria contained within 
the query for each transducer and frequency. 
Because maximax searches often involve millions 
of database records, the search is performed by a 
stored procedure in the ProcessedData database. 
Stored procedures are efficient to execute and avoid 
memory issues on the host computer because only 
results of the procedure are returned and not the 
millions of records that satisfy the search criteria. 
The maximax stored procedure is built into the 
database schema and has been optimized to return 
results in a reasonable time period. 

IV. Applications 



Design Limits 
ET2-1 |v| 

O Add Design Limit to Plot 


O Calculate Max-Max 
® Good Data Only 


I Refresh Menu 
1 Build Query 


| Make Query 


Save Query 


| Load Query 

Figure 5. QueryGUI user interface for creating SQL queries to the 
ProcessedData database. 


Mach 1.1, Alpha -4 , Beta -2 




Figure 6. 1/3-Octave results plotted by QueryGUI . 


D. CLV Reentry Test 

The Crew Launch Vehicle (CLV) Reentry test demonstrated the flexibility of DDS- Suite. The CLV Reentry test 
used a 2.8% First Stage Model to simulate atmospheric reentry. Reentry conditions can vary greatly making the 
acoustic environment difficult to measure. Angle-of-attack was varied from 90° to 180° and roll varied from 0° to 
1 80°. Model roll was controlled by BDAS, an auxiliary data system capable of motor control. BDAS was commanded 
through LAMDA to maintain a closed loop data system. 
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Mach = 0.8, Alpha = 7, Beta = 0, Roll = 0, 



Full Scale 1/3-Octave Frequency - Hz 


Third_F_09_01 g_a1 44_R1 46_S5_K001 _10.* 

Figure 7. Grid plot produced by QueryGUI shows the amplitudes for 150 sensors over the entire 
1/3-octave range. 


Data acquisition 



Figure 8. A graphical representation of processing and acquisition time for the CLV Reentry 
test. 


To efficiently measure data over the large ranges of model position, a combination of three data taking modes 
was used: (1) alpha-sweep; (2) phi-pause; and (3) OASPL peak. During the alpha-sweep mode, data were acquired 
constantly over a 45 second period while the model was swept through a 30° range of angle-of-attack. These data 
were then integrated into OASPL levels with angle-of-attack as the limits of integration. Alpha sweeps were run at 
five distinct roll angles. The purpose of the alpha sweeps was to identify regions of interest for further integration 
with fixed angle-of-attack and roll. These fixed data points were the third type of data, OASPL peak. While 
engineers made decisions about what OASPL peak conditions to test, the phi-pause data were acquired. 
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Near real-time decisions about which conditions for the OASPL peak points were made minutes after sweep data 
were acquired. Approximately 10 minutes separated the end of the alpha sweeps and the start of the OASPL peak 
data. Figure 8 shows the timing and duration of the acquisition and processing for each of the three data types. This 
novel data acquisition and processing allowed almost instantaneous analysis of a tremendous amount of data. 

E. CEV 80-AS Hot Helium Test 

Another test that demonstrated the flexibility and reliability of DDS-Suite was the CEV 80-AS test. As the 
single most expensive wind tunnel test in the CEV test program, data system robustness was critical. The test 
involved temporarily installing a 13 MW heater and its associated piping in the NASA Ames 1 1 -Ft Wind Tunnel to 
heat 600 psi helium to 700° F for simulation of the CEV abort conditions. The operational method of the hot gas 
delivery system limited each helium test point to 30 seconds and a limited supply of helium allowed for about 20 
test points per day making data system reliability more critical than usual. 

LAMDA was modified to interact with the helium delivery control system to minimize helium use and to ensure 
that data were acquired for every helium test point. Test requirements dictated that the helium temperature just 
before expansion through the four launch abort nozzles be at least 66 0° F, however the thermal mass of the piping 
system damped the temperature response. LAMDA monitored the helium temperature at the model and started data 
acquisition when it exceeded 660° F or when a timeout period expired. The timeout period was used to trigger data 
acquisition even in the event that system didn’t reach full temperature so that data were always acquired. At the end 
of the acquisition period LAMDA sent a signal to the helium system to start its shutdown sequence. DDS-Suite 
performed very well contributing to a successful test. 

F. CESTOLTest 

Although the processing and analysis portions of DDS-Suite were not used during the cruise-efficient short take- 
off and Landing (CESTOL) test in the AEDC 40- by 80-Ft Wind Tunnel, LAMDA was used to acquire single 
microphone and phased microphone array data. For this test LAMDA was modified to acquire video from an array 
mounted camera. The binary output files of LAMDA were modified to work with the OptiNav array processing 
software used for the test. Data acquisition was triggered by the user because closed loop control was not allowed by 
the facility. LAMDA performed flawlessly acquiring more than 1 TB of data. 

Summary 

At NASA Ames, requirements for a reliable, high-channel count, fast throughput dynamic-data system have 
been met with the development and deployment of DDS-Suite. Data acquisition, processing, and analysis of up to 
672 channels of dynamic data with sample rates exceeding 200 kHz with phase differences of less than 0.01° has 
been demonstrated. Modularity and scalability make DDS-Suite useful for low or high channel-count tests in a 
variety of facilities. Automated acquisition and processing provide preliminary data in less than five minutes. 
QueryGUI is a user-friendly analysis tool to search and plot processed results in near real-time. Several large 
channel-count aeroacoustic test have been completed successfully using DDS-Suite. Near real-time data is critical 
for efficient, cost effective testing. 
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